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Requirements for Metro Ethernet Forum (MEF) Ethernet-Tree (E-Tree) 
Support in Layer 2 Virtual Private Network (L2VPN) 


Abstract 


This document provides functional requirements for the support of 
Metro Ethernet Forum (MEF) Ethernet Tree (E-Tree) in multipoint Layer 
2 Virtual Private Network solutions (referred to as simply "L2VPN"). 
It is intended that potential solutions will use these requirements 
as guidelines. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Not all documents 


approved by the IESG are a candidate for any level of Internet 
Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7152. 
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Copyright Notice 


Copyright (c) 2014 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
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1. Introduction 


This document provides functional requirements for the support of 
Metro Ethernet Forum (MEF) Ethernet Tree (E-Tree) in multipoint Layer 
2 Virtual Private Network solutions (referred to as simply "L2VPN"). 
It is intended that potential solutions will use these requirements 
as guidelines. 


A considerable number of service providers have adopted Virtual 
Private LAN Service (VPLS) to provide MEF Ethernet LAN (E-LAN) 
services to customers. Service providers currently need a simple and 
effective solution to emulate E-Tree services in addition to E-LAN 
services on their MPLS networks. 


Service providers also expect E-Tree support in any newly developed 
L2VPN technologies. 


1.1. Conventions Used in This Document 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


2. IETF Multipoint Ethernet L2VPN Services 
2.1. VPLS 


VPLS [RFC4761] [RFC4762] is an L2VPN service that provides 
multipoint-to-multipoint connectivity for Ethernet across an IP or 
MPLS-enabled IP Packet Switched Network (IP/MPLS PSN). VPLS emulates 
the Ethernet VLAN functionality of traditional Ethernet networks. 
Thus, in VPLS, the customer Ethernet frame is transported over the 
IP/MPLS PSN from the ingress Provider Edge (PE) to the egress PE 
where the destination is connected based on the Ethernet frame 
destination Media Access Control (MAC) address in the context of the 
virtual switching instance (VSI) to which it belongs. 


2.2. Ethernet Virtual Private Network (E-VPN) 
E-VPN is an enhanced L2 service that emulates an Ethernet VLAN across 
an IP/MPLS PSN, primarily targeted to support large scale L2VPNs with 


resiliency requirements not satisfied by other L2VPN solutions. 


E-VPN is currently under development. Please refer to [EVPN]. 


Key, et al. Informational [Page 3] 


RFC 7152 Requirement E-Tree in L2VPN March 2014 


3. MEF Multipoint Ethernet Services 
MEF has defined two multipoint Ethernet service types: 
- E-LAN (Ethernet LAN), multipoint-to-multipoint service 
- E-Tree (Ethernet Tree), rooted-multipoint service 
For the full specifications, please refer to [MEF6.1] and [MEF10.2]. 
3.1. Similarities between E-LAN and E-Tree 
The following are the similarities between E-LAN and E-Tree services. 

- Data frame is an Ethernet frame. 

- Data forwarding is MAC-based forwarding. 

- A generic E-LAN/E-Tree service is always bidirectional in the 
sense that ingress frames can originate at any endpoint in the 
service. 

3.2. Differences between E-LAN and E-Tree 
Within the context of a multipoint Ethernet service, each endpoint is 
designated as either a Root or a Leaf. A Root can communicate with 
all other endpoints in the same multipoint Ethernet service; however, 
a Leaf can only communicate with Roots but not Leaves. 
The only differences between E-LAN and E-Tree are: 

- E-LAN has Root endpoints only, which implies there is no 
communication restriction between endpoints. 

- E-Tree has both Root and Leaf endpoints, which implies there is 
a need to enforce communication restriction between Leaf 
endpoints. 
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3.3. E-Tree Use Cases 


Table 1 presents some major E-Tree use cases. 


HS 229522 +== 225335 ds === 2=52>5 S===253=:==== + 

| Use Case | Root | Leaf | 
$ A O O E E AT tes += == $ + 
| 1 | Hub £ Spoke VPN | Hub Site | Spoke Site | 
$ A O O aaa dE == E $ + 
| 2 | Wholesale Access | Customer” s | Customer's | 
| | | Interconnect | Subscriber | 
$ A O A AE EE $ $ + 


| Radio Access | RAN Base | 
| | | Network (RAN)| Station | 
| | | 
| | | 


| | Network 

| | Controller 

+---4--------------------------- $ a 4+------------ + 

| 4 | IEEE 1588 PTPv2 | Precision | PTP Client | 

| | Clock Synchronisation | Time Protocol | 

| | [IEEE1588] | (PTP) Server | | 

AA $ Hi do + 
5 Internet Access Broadband Subscriber 

[TR-101] Network 

| | | Gateway | | 

AA E E E E tt nt + 

| 6 | Broadcast Video | Video Source | Subscriber | 

| | (unidirectional only) | | 

AA $ R 4+------------ + 

| 7 | Broadcast/Multicast Video | Video Source | Subscriber | 

| | plus Control Channel | | 

AA E $ do + 

| 8 | Device Management | Management | Managed 

| | | System | Device | 

AA E EAE do 4+------------ + 


Table 1: E-Tree Use Cases 


Common to all use cases, direct L2 Leaf-to-Leaf communication is not 
required or must be inhibited. 


If direct L2 Leaf-to-Leaf communication is not allowed due to a 
security concern, then E-Tree should be used to prohibit 
communication between Leaf endpoints. Otherwise, E-LAN is also a 
feasible option. 
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3.4. Generic E-Tree Service 


A generic E-Tree service supports multiple Root endpoints. The need 
for multiple Root endpoints is usually driven by a redundancy 
requirement. Whether a particular E-Tree service needs to support 
single or multiple Roots depends on the target application. 


A generic E-Tree service supports all the following traffic flows: 
- Ethernet Unicast from Root to Leaf 
- Ethernet Unicast from Leaf to Root 
- Ethernet Unicast from Root to Root 
- Ethernet Broadcast/Multicast from Root to other Roots and Leaves 


- Ethernet Broadcast/Multicast from Leaf to Roots 


A particular E-Tree service may need to support all the above or only 
a subset depending on the target application. 


4. Problem Statement 
4.1. Motivation 


L2VPN can be used to emulate MEF E-LAN service over an IP/MPLS PSN. 


Service providers also require E-Tree support in L2VPN. 
4.2. Leaf-to-Leaf Communication Restriction 


In this section, VPLS is used to illustrate the problem; however, the 
same principle applies to other L2VPN technologies. 


VPLS treats all attachment circuits (ACs) equally (essentially as 
Roots, although they not classified into Root or Leaf) and provides 
any-to-any connectivity among all ACs. VPLS does not include any 
mechanism for communication restriction between specific ACs. 
Therefore, it is insufficient for emulating generic E-Tree service 
over an IP/MPLS PSN. 


As an example of the problems not addressed in VPLS solutions, 
consider the scenario in Figure 1 where there are two PEs, each with 
a Root AC and a Leaf AC and where VPLS is used to emulate an E-Tree 
service interconnecting these ACs over an IP/MPLS PSN. 
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5% 


Di 


«===> E=Tree-====2======>3 > 
4+--------- + 4+--------- + 
PE1 PE2 

+---+ +---+ +---+ +---+ 
CE1+----- AC1----+--+ | | | | +--+----AC3----- +CE3 | 
+---+ (Root AC) | |v] | Ethernet | |v | | (Root AC) +---+ 

| | s +--+----- PW----- +--+ S | | 
ho. CEA MEJIA to 
| CE2+----- AC2----+--+ | | 9 +--+----AC4----- +CE4 
+---+ (Leaf AC) | +---+ +---+ | (Leaf AC) +---+ 

4+--------- + 4+--------- + 


Figure 1: Problem Scenario for Leaf-to-Leaf Communication Restriction 
When PE2 receives a frame from PE1 via the Ethernet pseudowire (PW), 
- PE2 does not know which AC on PEl is the ingress AC 
- PE2 does not know whether or not the ingress AC is a Leaf AC 
- PE2 does not have sufficient information to enforce the Leaf-to- 
Leaf communication restriction 
Examples where the problems arise: 
- Customer Edge 2 (CE2) sends a Broadcast/Multicast Ethernet frame 
to PEl via AC2 
- CE2 sends a Unicast Ethernet frame to PEl via AC2 with a 


destination MAC address corresponding to CE4’s MAC address 


Note: Figure 1 is a hypothetical case solely used for explaining the 
problem; it is not meant to represent a typical E-Tree service. 


There are some possible ways to get around this problem that do not 
require extensions to existing VPLS solutions, but they all come with 
significant design complexity or deployment constraints. 

Requirements 
1. Functional Requirements 


The following are the E-Tree L2VPN functional requirements: 


(1) A solution MUST prohibit communication between any two Leaf ACs 
in an L2VPN instance. 


(2) A solution MUST allow multiple Root ACs in an L2VPN instance. 
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(3) A solution MUST allow a Root AC and Leaf AC of an L2VPN instance 
to coexist on any PE. 


5.2. Applicability 


A solution MUST identify the L2VPN technology ([RFC4761], [RFC4762], 
[EVPN]) to which the solution is applicable. 


5.3. Backward Compatibility 


A solution SHOULD minimise the impact on VPLS and E-VPN L2VPN 
solutions, especially for the MEF E-LAN services already in 
operation. 


A solution SHOULD be backward compatible with the VPLS and E-VPN 
L2VPN solutions. It SHOULD allow a case where a common L2VPN 
instance is composed of both PEs supporting the solution and PEs not 
supporting it, and the Leaf-to-Leaf communication restriction is 
enforced within the scope of the compliant PEs. 


5.4. External Network Network Interface (ENNI) 


A solution SHOULD support Root Operator Virtual Connection (OVC) End 
Point, Leaf OVC End Point and Trunk OVC End Point specified in 
[MEF26.1]. 


6. Security Considerations 


This document introduces a requirement of prohibiting communication 
between any two Leaf ACs in an L2VPN instance. In some use cases, 
such a requirement is imposed because of security reasons. Other 
than that, there are no additional security considerations beyond 
those already described in [RFC4761], [RFC4762], and [EVPN]. 
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Appendix A. Frequently Asked Question 


A.1. Are E-Tree Requirements Addressed in the Virtual Private Multicast 
Service (VPMS) Requirements? 


VPMS requirements are defined in [VPMS]. 
The focus of VPMS is to provide point-to-multipoint connectivity. 


VPMS provides single coverage of receiver membership (i.e., there is 
no distinct differentiation for multiple multicast groups). A VPMS 
service supports single or multiple Root ACs. All traffic froma 
Root AC will be forwarded to all Leaf ACs (i.e., Point-to-Multipoint 
(P2MP), from Root to all Leaves). The destination address in an 
Ethernet frame is not used in data forwarding. As an optional 
capability, a VPMS service may support reverse traffic from a Leaf AC 
to a Root AC (i.e., point-to-point (P2P), from Leaf to Root). 


In contrast, the focus of MEF E-Tree is that a Leaf can only 
communicate with Roots, not Leaves. 


A generic MEF E-Tree service supports multiple Root endpoints. 
Whether a particular E-Tree service needs to support single or 
multiple Root endpoints depends on the target application. 


As discussion in a previous section, a generic MEF E-Tree service 
supports all the following traffic flows: 


- Ethernet Unicast bidirectional Root to/from Root 

- Ethernet Unicast bidirectional Root to/from Leaf 

- Ethernet Broadcast/Multicast unidirectional Root to all Roots 
and Leaves 

- Ethernet Broadcast/Multicast unidirectional Leaf to all Roots 


A particular E-Tree service may need to support all the above or only 
a subset depending on the target application. 


The IETF’s VPMS definition and MEF’s E-Tree definition are 
significantly different. 


VPMS may be acceptable in cases where E-Tree service is needed, such 
as in the following cases: 


- No Unicast traffic from Root destined for a specific Leaf (or 
there is no concern if such Unicast traffic is forwarded to all 
Leaves) 

- No traffic between Roots 
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